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Abstract 


Applications such as multi-Hiedia multi-source information services, desk-top 
conferencing, joint editing and preparation of documents etc., allow users of 
a network to participate in co-operative work across the network These ap- 
plications require the underlying network to provide group communication 
features such as multicast addressing and group management. Further, to use 
the available network bandwidth efficiently, it is essential that the multicast 
touting algoiithins pioduce low-delay loiites In this piojett, the iriipleinen- 
tation iispt'ils ofpioviding group coumiunicntion sijjjpoit have been studied 
The lETF-MBONE experiment has been emulated to set up a virtual network 
over piuts of the HT Kanpur campus LAN. This virtual netwoik foims an IP 
multicasting backbone (MBONE) to route multicast packets among hosts on 
different subnets in the network. Three machines on tlu'ee different subnets 
in the Campus network have been configured as multicast routers. These 
routers loute multicast packets to/from hosts on these three subnets. These 
machines also provide operating system support for sending and receiving IP 
multicast packets Two adaitional machines have been configuied to support 
only sending of multicast packets. For configuration of MBONE, public do- 
main software available over the Internet has been customized for the Campus 
network. The proper functioning of the campus multicast backbone has been 
demonstiatod using a public domain software which, initiates and manages 
multicast sessions 
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Chapter 1 


Introduction 


A computer network is an interconnected collection of several autonomous 
computers This network may be a small local area network (LAN), or a 
large network of intet connected LANs. An application program executing 
on one machine in the network may inteioperate with applications execut- 
ing across the network to provide a service varying from simple ASCII file 
transfer to the more complex service such as multi-media document retrieval 
and transfer. The network architecture, should, therefore provide support 
for distributed applications, network management and maintain satisfactory 
performance Fuither, services provided by the underlying network must be 
engineered for efficient execution of the network applications. 


1.1 Ti'aditional Network Applications 

Different applications require different services from the underlying network. 

The following are typical examples . 

1. Applications such as information services, directory services, library ser- 
vice.s, etc., rcquiie remote access to databases 

2. Airline reservation systems, inventory control systems, toller systems, 
commercial credit card systems etc,, require remote updatton of data- 
bases, in addition to I'emote access and transactions processing 

3 Electronic mail between uscis on the netwoik i' 0 (jiiit(’s that mes.sagos 
should be sent, received, processed and forwarded Usually, this storc- 
aiul-foi Will'd service is implemented over the u.sua! network sei vires, 

4. Applications requiring distributed computing power or load shaiing need 
the network to perform the assigned task witliin some predefined maxi- 
mum delay 
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1.2 Emerging Network Applications 

With the cwailability of very lugh speed communication links using optical 
fibre technology, high power workstations and efficient VLSI implemcntable 
algorithms for encoding and decoding of various media like video and voice, 
theie IS an emerging set of applications winch can be supported on a data 
notwoik Some of these aie Multimedia rimlti-souice infonnation setvices, 
integrated voice and graphic mail, desktop multimedia conferencing, network 
based automation in industrial applications such as process control, joint edit- 
ing and prepaiation of documents over the network, on demand video, and 
telemedicine The RAPPORT system [1) and the Multimedia Conferencing 
project [11] are two examples which focus on the networking requirements and 
user interface development for real time conferencing applications 

1.3 Network Support for Co-operative Work 

Common to this emerging class of applications is the requirement for the 
network to support ro-operative work between remote usois Tlus support, 
provides an efficient method by which remote users can inteiact within a group. 

The Figure 1 1 illustrates a typical classification of co-operative work sup- 
port features over a network as given by Sakata [22] According to this classifi- 
cation, the co-opoiative work-support features can be divided info two bioad 
classes: 

1. those allowing shared workspace, such as audio, video communication 
support and group co-ordination, and 

2 those allowing shaiing of the information space viz integrated support 
for personal and group work, and interactive data exchange and handling 
within the group 

In case of applications such as multi-source information services, the latter 
class of foatuics is important, whereas, in case of applications like multi-media 
conferencing, both classes of features should be provided by the group com- 
munication service on the underlying network. 

In a network of interconnected LANs, hosts on the network can partici- 
pate m co-opeiative work if the network provides a low level .service with some 
basic group communication features such as gioup addressing and group man- 
agement, The concept of grouping processes has traditionally been used in a 
distiibutcd systems onviionment [3] to achieve goals such <is paiallel process- 
ing, increased data availabilty, shared resources, reduced response times, and 
reliablility. Similarly, in distributed applications such as confonMicing, group 
multicast or group .uldrcss'ing lediu’cs tiriiisinissioii ovin lieaii.s on tin* sianli'i 
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(shared information 
space) 


Integrated support for personal work 


Figuie 1 !• Co-operative Woik-support Fcatuics 

and allows a host to send information to other hosts in the group, wliose ad- 
dress IS unknown or (hangeable This concept of group addratisuig is widely 
used in LANs. 


1.4 Group Communications Over Networks 

To illiLstrate typical group communication features, a netwoik of intercon- 
nected LANs IS considered as shown in the Figure 1.2. 

Hosts A, B, C, D, and E are located on LANs 1, 2, 3, 4, 5 respectively. 
Now, consider the following scenario : 

# Hosts B, C, D, and E are members of group gl. 

• Host A does not belong to gioiij> gj but desires to send piukc*ts to gl. 
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Figute 1 2 A Typical Network of Interconnected LANs 

In order that host A can send packets to group gl, and for hosts B, C, D, 
and E, can receive these group addressed packets, the following requirements 
must bo met 

• Host A must be able to send packets with destination address of the 
packet as gl Hosts B, C, D, and E should be capable of iccognizing the 
packets with the destination address gl as their own The concept of 
sending packets to a pie-defiucd group of hosts is called multicasting. 

• A host can receive packets if it belongs to a group Therefore, a mech- 
anism for subsiibing and un.subscribing to a gioup slioiild lie available 
witliin every host that wants to participate in co-opoiativc work over 
the notwoik. Also, each of the gateways Gl, G2, G3, G4, and Gh must' 
know of the gioups on each of its links to forward the group addressed 
packets to all members of the group. Such group rnanagciiient functioii.s 





iHM'd fo l)(‘ piovuUhI by d groujj uianagotnoiit sorvu'c cxfH iihiig in 
botli tlu' lioits and tlic loutois 

• Finally, it is dosuable that multicast packets must bo deliveicd to all 
membois' of the group with rniminiun delay This is crunal iii applica- 
tions siuh as ( onforcMiting ami lesouico location The ilelay pioperties 
of laig(' ml(M iK'twoi ks aie affeded by the gre«it<’i geogiaphic extent and 
laigo nuinbei of links and switches Howcvoi , the use of high speed links 
and low-delay long distance communication links can significantly loduce 
the delay. It is thoifore essential that multicast routing algorithms 
pioduce low delay routes. 

One of the most widely used Internetwoiking technolo gy is the DARPA 
TCP/IP Internet [7] The TCP/IP Internet provides a set of network stan- 
dards whuh can be used to communicate across any set of interconnected 
netwoiks The next .section gives a biiof oveivicw of the TCP/IP Internet to 
understand how some basic group communication sei vices can be provided 
within this netwoik architecture 


1.5 The TCP/IP Internet - An Overview 

The TCP/IP Internet is an unified iiitercoiinectioa of independent networks 
providing thicc sets of sei vices, as shown m the Figure 1,3, At the lowest level, 
it provides a connectionless datagram delivery semce. At the next level, it 
provides a leliable transpoit service. At the highest level application services 
such as remote login, file transfer dnd e-mail are provided. 


Application Services 


Reliable Transport Service 


Connectionless Packet Delivery System 


Figui<> I 3 The threo lompononts of the Intel net Scrviios 
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Figure 1,4‘ The four conceptual layers of TCP/IP 

The Figure 1 4 shows the Internet layeiing Tins figuie also shows the 
objects passed between layers. The network interface layer is synonymous 
to data link layer as defined in the OSI protocol stack The network layer is 
concerned with issues such as the exact foiinat of Internet datagi arris, host and 
network addie,s.sing, and the routing of datagrams across the Internet This 
layer also defines a connectionless datagram delivery service The trans'port 
layer protocols provide end-to-cnd connections between application processes 
executing across the network. 

An uureliable datagram service at the transport level provides a connec- 
tionless communication among the applications, whereas the Traasmission 
Control Protocol (TCP) provides a reliable, flow-controlled, stream service 
between two applications. Figure 1.5 shows the dependencies among ma- 
jor higher level TCP/IP protocols. Tlie details on Internetworking with the 
TCP/IP are givc'ii in (7]. In the TCP/IP piotoeol suite, the Internet layer 
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Figure 1 5. Dependencies among the major TCP/IP Protocols 

[14] performs the addressing and routing functions. Thus group communica- 
tion services such as group addressing, group management and routing are 
extensions to the Internet layer 

1.6 Objectives Of This Project 

As discussed above, applications such as multi-source multi-media information 
services, desktop conferencing and joint preparation of documents need group 
communication support services on a netwoik. Till recently, there were no 
standards specified for group communication services in the TCP/IP Inter- 
net, although, a standard for group management, called the Internet Group 
Managornont Piotocol (ICMP) did exist [16]. However, due to increasing in- 
frastructure support such as liigh speed links, and switches etc., efforts towards 
implementing experimental protocols for multicasting, multicast routing and 
group management have gained momentum since tlie caily ’90s. Prc.sently a 
standard exists foi the extensions to IP for multicasting and ICMP [19] but 
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yet there is no standard for multicast i outing 

Some of the fiist effoits towards developing group communications services 
over the Internet were made by the Internet Engineering Task Force (IETF). 
The IETF carried out the Audiocast expeiiment (23) to transmit live audio 
and video from the IETF meeting site to destinations across the world. A 
fallout of this experiment was the Multicast Backbone or the MDONE setup 
across various Internet sites over the world. The MBONE idea is to create a 
virtual network layered on top of portions of the physical Internet to support 
routing of the IP multicast packets. In the MBONE experiment, IGMP was 
used for group management and a distance vector style multicast routing 
algorithm (DVMRP) was implemented for routing of the IP multicast packets. 

In this project, the enchancements of a network site to provide host multi- 
cast, group management and multicast routing have been studied. The IITK 
campus network has an extented LAN topology with Internet TCP/IP imple- 
mentation An experimental Multicasting Backbone has been setup to provide 
a piimitive level of group communication service over the IITK nctwoik, based 
on the IETF MBONE experiment The public domain software available over 
the Internet has been used for this purpose. This project follows the Internet 
architecture m totality. 

1.7 Organisation of This Thesis 

The rest of tliis thesis is organised as follows : 

In Chapter 2, details about properties of group communication and group 
management on the Internet have been described. This chapter also describes 
how hosts on the Internet can send/receive multicast packets to/from a pre- 
defined group 

The routing and forwarding algorithm for the multicast piickets as stan- 
dardised in the Internet is explained in Chapter 3. 

In Chapter 4, the details of the enhancements on the campus network for 
multicasting, routing and group management are given, 

Chapter 5 concludes with scope for further work 
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Chapter 2 


Group Communications Over 
Internet 


As seen in chapter 1, at the lowest level, group communication services 
provided by a network deal with issues such as group addressing, group man- 
agement and the efficient routing of the group addressed packets. The Internet 
Authorities Board (LAB) provides a standard [19] for IP host multicasting (or 
group addressing) and group management. These protocols have been devel- 
oped over a predefined group communication model. In this chapter, we first 
study the parameters which influence the design of the group communication 
protocol supported by a network. The Internet group communication model is 
presented next In the following section, the features of the Internet standard 
for host IP multicasting are reviewed along with an overview of the Internet 
Group Management Protocol (IGMP), which is used to carry routing updates 
and group membership reports in the IP multicast implementation. 

2.1 The Group Communication Model 

Protocol design for group communications is based on a pre-defined group 
communication model. This model is defined by pararnctcr.s such as the group 
types, group characteristics, packet delivery characteristics and the underlying 
network environment. These parameters are, in turn, defined by the applica- 
tions which need to use the features of group communications The various 
parameters on which the group communication model depends are given in 
the Tables 2 1 and 2,2 A typical example of this would be the group commu^ 
nication model for the Internet. 


2,1.1 Internet group communication model 

In the Internet, the group communication features are designed to .support 
distiibutod apphration.s across the Intornot. S.Df'criiig and E Chcriton [10] 
have defined a model whicli has boon adopted for the design of the II’ iriulti- 
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casting and multicast routing in the Internet This model specifics the types 
of groups, the group characteristics, the datagram delivery characteristics and 
the underlying communication environment 


Group Type 

features 

Usage 

Local 

all members of the group lie on the same 

Distributed 


LAN or AdministMtive Domain. 

systems 

Sparse 

no. of members are few and belong 
to seperate Administrative Domains. 

Conferencing 

Traiisieat 

formed only at the time of usage 

ff 

Permanent 

Long lived 

news 

Pervasive 

Large no. of members, atleast one 
member per group on each LAN 

Directory Server. 


Table 2.1 Types of groups. 


group 

character. 

features 

usage 

Open 

sender need not be a member of the group 

directory 

servers, 

closed 

sender must be a member of the group 

conferencing 
news, name 

static 

membership remains undisturbed over long 
intervab of time 

name servers 

dynamic 

group members can join or leave the group 
at will wiUiout negotiations with other 
members of the group. 

conferencing 


Table 2,2 Group Characteristics. 
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In this inodol, (oninuinicntuin is piovulod by iniilh-tU ( ('ss iiptvvoiks (LANs 
and possibly satellite netwoiks) iiitci connected by packet switching nodes in 
ail arbitrary topology A typical example is shown in the Figure 2 1 



Figure 2.1' A typical Internet toplopy 

Point-to-point links may provide additional connections between the sw- 
itching nodes or from switching nodes to isolated hosts, but almost all hosts 
are directly connected to LANs. The LANs are assumed to support local net- 
work multicasting The supported group type is open and its characteristics' 
are dynamic There is no limit on the number of members in a group All 
group addresses are allocated when the group is initiated, except for a few 
pre-assigned permanent ones and the addresses are released when the group is 
dissolved. Thus, a group exists as long as there is atleast one member in the 
group, except in the case of a few well known permanent groups. The perma- 
nent groups have well known administratively assigned IP multicast addre-sses. 
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When implementing the IP multicast, the designeis have assumed that 
the imiltiiast packet is dolivc’u’d with the smiie best efTort delivery [7] as 
the IP unicast datagrams This implies that packet loss slioiild be handled 
by the upper laycis The delivery delay is assumed to be minimized with 
the implementation of multicast routing algorithms which produce low delay 
routes Since the IP multicast addressing and routing are extensions of Inter- 
net layer, the Internet protocol wliicli provides the connectionless datagram 
delivery mechanism, is first reviewed below 


2.2 Internet Protocol 

The Internet Protocol (IP) provides three basic definitions 

• IP defines the basic umt of data transfer used throughout the Internet, 
whii h 1 ’* < aiU’cl ns tlio TP dntnK'ani Tints, TP spnrifies Ihn ('xnrt foirnat 
ot all data as it passes acioss a TCP/IP iuteiiiet. 

• IP software perfoims the routing function, choosing a path over wliicli 
data will be sent 

• IP includes a set of lulcs that embody the idea of uiiieliable packet 
delivery. The rules characterize how hosts and gateways should process 
packets, how and when error messages should be generated, and when 
packets can be discarded. 

2.2,1 The Internet datagram 

The Internet datagram is divided into header and data areas The header 
contains the source and destination IP addresSj and additional type fields 
that identify the contents and characteristics of the datagram, The datagram 
header is shown in the Figure .2,. 2.. Because the datagram processing occurs 
m software, the contents and format are not constrained by any hardware. 
The significance of each field of the datagram header is given in [7], In the IP 
multicast extensions only a few fields of the IP header are of significance. 

They are . 

• Time To Live 8 bits . 

The time to live specifies how long, in .seconds, the datagram is allowed 
to remain in the Lilernet, Gateways and hosts which [iiocess the IP 
datagrams must decrement the time to live field as time passes and 
discard the packet when the time to live expires. Since estimating the 
lapsed time is difficult, a simple iiile is followed at every gateway along 
the path from the source to the destination : 
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DESTINATION IP ADDRESS 


IP OPTIONS (IP ANY) 


PADDING 


DATA 


Figure 2 2. Format of an Internet Datagram 


IF (IP-ttl >= 1) 
decrement IP-ttl 

forward the packet to the next-hop gateway 
in the path to destination 
ELSE 

discard it. 


This field has been used to limit the scope of travel of a multicast data- 
gram iLsing a threshold mechanism. This is explained later in the chap- 
ter. 

• Source IP Address ; 32 bits • 

• Destination IP Address : 32 bits . 
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Figure 2.3 Forms of Internet Add losses 
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Figure 2 4: Host IP Implementation - Layered Model 

• On those networks that are up and reachable within the IP tiine-to-hve 
of the multicast datagram, the attached multicast router completes the 
datagram delivery by transmitting the datagram as a local multicast 

From the above, the following implementation issues arise: 

1. How can hosts send IP multicast datagrams? 

2. How can hosts receive IP multicast datagrams? 

3. How do routers know of the group memberslups on its links? 

Tlus standard addresses the above issues on the basis of the host IP im- 
plementation layered model shown in the Figure 2 4 

In tills model, ICMP and IGMP aie assumed to be implemented for hosts 
which confirm to the level 2 IP multicast. For the level 1 hosts, the host 
IP implomontation should only support the transmission of the IP multicast 
datagrams At the lowest level m these extensions is the mapping of the IP 
multicast address to thi link level address (e g. IP to Ethernet address 
mapping). In the following section the multica.s't addres.s resolution problem 
is discussed. 
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Figure 2 5 The encapsulation of IP datagram into a frame 

2.3.1 Resolving the multicast address 

When datagi ams move from one machine to another, they must be transported 
by the underlying physical network The network hardware does not under- 
stand the datagram format but merely encapsulates the datagram by adding 
an extra frame header The frame header contains besides other fields, the 
physical (hardwaie) addresses of the souice and destination host machines 
Thus, as shown m the Figure 2 5, the entire datagram travels in the data 
portion of the network frame 

The mapping of the Internet address to the netwoik specific physical ad- 
diess is handled by low level protocol such as ARP (7] 

IP multicast addressing 

In the IP, the datagram's destination address specifies the recipient of the 
datagram For multicasting a datagram, the destination IP address is a Class 
D IP multicast address of the form : 


1110 


Group Identification 


The first four bits identify the address as multicast. The remaining 28 bits 
identify a particular host group. The group field does not identify the origin 
of the group and does not contain any network address. When expiessed hi 
dotted decimal notation, the multicast addresses lango from : 


224.0.0.0 to 239.255 255 255 


The address 224 0.0.0 cannot bo as.signed to any gioup The addres.s 
224 0 0 1 has been permanently assigned to the all.hosts^group and is u.se(l 
to reach all hosts and gateways capable of rniiiticast on a local lu'twork. The 
addioss 224 0 0 4 is ased to addiess only Liio loufri'i} paitn ipaLiiig in tlio iniil- 
ticast. All the touting queries and updates are srnit to tins luldress 
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An IP multicast address can only be used as destination address It cannot 
be used as a source address or m the source route. Also, no Intel net Control 
Messages (ICMP) [7] such as destination unreachable or time exceeded can be 
generated about multicast datagrams 

The mapping of the IP address to the link level address is done by the 
Local Network module (refer Figure 2.4), To undei stand the mapping, the 
Ethernet local network module is considered 

Ethernet multicast addressing 

The Ethernet directly supports the sending of local multicast packets by al- 
lowing multicast addresses in the destination field of the Ethernet frames. An 
Ethernet multicast address is identified by the use of low-order bit of the high 
order octet m the six octet Ethernet address. In dotted decimal, this address 
IS identified by 


01 00 00 00.00 00 

The Ethernet hardware can be configured to accept packets for a small set 
of multicast addresses besides its assigned physical (unicast) address and the 
broadcast 

Mapping IP address to Ethernet address 

The standard specifies the mapping of the IP multicast address to the Ethernet 
address as follows: 

Place the low-order 23 bits of the IP multicast address into the 
low-order 23 bits of the Ethernet multicast address 01.00.5e.00.- 
00.00 

For example, the IP multicast address 224.0 2 1 is mapped to 01.00.5e 00.- 
02.01 Ethernet address. 

This mapping is not unique. Because IP multicast addresses have 28 sig- 
nificant bits that identify the multicast group, more than one group may map 
onto tlie same Ethernet multicast address, This scheme has been chosen as a 
compromise, by the designers On the one hand, using 23 bits of the 28 bits 
for a hardware address means most of the multicast address is included. This 
set IS large enough so the chances of two groups choosing addresses with all 
low-order bits identical is very small. On the other hand, arranging for IP 
to use the fixed part of the Ethernet multicast address space makes debug- 
ging easier and eliminates interference between IP and other protocols that 
share an Ethernet. To avoid receiving packets not destined for that hosts, the 
IP software should carefully check addresses of nil incoming (iatagrarns and 
discard the unwanted ones. 
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Unicast vs Mtilticast address resolution inechanistn 

Address resolution in the case of unicast datagram is done using the Address 
Resolution Protocol (ARP) [7] 

In tcisc of multicast IP datagiains, the destination address specifies a gioup 
of hosts The multicast physical address (for eg , Ethernet) depends only on 
the group addiess The address mapping as described for Ethernet allows 
hosts’ network interfaces to transport multicast IP packets across the network. 
This mechanism is static when compared to the dymunic binding provided in 
case of the unicast datagram transmission, in the sense that a change in the 
physical address of the destination host does not alter the destina- 
tion physical address of the transmitted datagram The receiving host 
should only alter its hardware address filter to recognise that physical address 
as its own. 

2.3.2 Extensions for sending IP multicast datagrams 

For sGiuliiig an IP datagram to a pmticular IP (Icstinatioii addiess, the upper 
layer protocol module specifies the IP destination address to be filled m the 
destination address of the IP datagram header. This destination address may 
be unicast or multicast. The modifications requiied to send the multicast 
datagram are summarized below, with reference to Figure 2 4 The complete 
details are available in [19]. 

In case of unicast datagrams, the IP service interface invokes the SendIP 
operation to send IP datagrams. In case of the multicast datagrams the same 
SendIP operation can be used, with the destination address as the desired 
IP multicast address (class D) This interface should additionally provide op- 
tions that can be specified by the upper layer protocol, when submitting the 
datagram for transfer across the network, for 

• specifying the TTL value in the IP datagram header, 

• the netwoik interface on which the datagram should bo sent and 

• whether the datagram should be looped back to the sending host. 

To support the multicast IP datagrams, the IP module should be able 
to recognize IP host group addresses when routing outgoing datagrams. For 
routing, the following logic should be implemented . 

IF IP-destination is on the same local network, 

OR IP-destination is a host group 

send datagram locally to the IP-destination 

ELSE 

send datagram locally to GatewayToC IP-destination ) 
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If tho sending host is also a member of the destinatioii-gionp, a ropy of tlic 
datagram mn^t be looped back luiloss inhibite<l by the nppei layer piotocol. 

No change to the local network inteiface is necessaiy This interface only 
needs to support the destination address as a Class D add i ess when it invokes 
the SendLocal operation to pass the datagram to the local network module 
For networks that directly support multicasting, such as Ethernet or other 
network topologies conforming to the IEEE 802 2 standard, the local network 
module should incorporate the mapping function for mapping the IP multicast 
address to the Local network multicast address. This mapping has already 
been explained for the Ethernet, in Section 2 3.1. Details of mapping in case 
of networks not supporting hardware multicast are given in [19). 

2.3,3 Extensions for receiving IP multicast datagrams 

For an upper-layer protocol module to receive multicast datagrams addressed 
to a particular group, it must fiist be a member of that gioup Thus, ex- 
tensions to the IP for receiving multicast datagrams essentially requires that, 
it provides some mechanism by which the upper-layer protocol modules can 
subscribe or un-subscribe to a hosts group, identified by a Class D IP address 
The IP Service Interface must be extended to provide two new operations 


JoinHostGroup(group_a<i<iress , interface) 

LeaveHostGroup (group address , interface) 

Hosts could join the same group on more than one mteiface. It should 
also be possible for more than one upper-layer protocol modules to request 
membeiship of the same group. 

To support the reception of the multicast IP datagrams, the IP module 
should maintain a list of the host group memberships associated with each 
network interface An incoming datagram destined to one of those groups 
should be processed exactly the same way as datagrams destined to one the 
host’s individual addresses. To correctly handle the incoming datagrams, the 
following logic should be implemented. 


IF IP-destination group address is one of ours 

and it arrived on the network interface on which 
this host is a ’nember 
accept the multicast IP-datagram 
ELSE 

discard the datagram. 
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The list of the host group memberslups should be updated in response 
to the JoiiiHostGroup and LeaveHostGroup requests from the upper-layer 
protocols. The IP module must also be extended to implement the IGMP 
protocol as specified in (19) A brief summary of this protocol is given in the 
next section 

The local network interface should deliver the incoming local network mul- 
ticast packets to the IP modulo using the same RcceiveLocal optaation a.s 
in the case of umcast packets Additionally, this interface should provide two 
new operations for the IP module to specify which multicast packets the local 
network module should accept. 

These are 

JoinLocalGroupC group- address ) 

LeavelocalGroup( group-address ) 

To support the reception of IP multicast datagrams, the local network 
module must set the address filter of the netwoik hardware interface, to rec- 
ogmze the desired multicast addresses. For interfaces with inadequate filtering 
capability, the address filtering should be done within the local network in- 
terface softwaie This is not mandatory For network.? supporting only pure 
broadcast, the packets have to be accepted and passed to the IP module for 
IP-level filtering. 


2.4 Internet Group Management Protocol 

Similar to the ICMP in its relationship to IP, the Internet Group Manage- 
ment Protocol or IGMP is the TCP/IP standard for group mangement in the 
Internet The IGMP is used by hosts on the Internet to communicate group 
membership information with the gateways and by the gateways to commu- 
nicate the group information among themselves. Like ICMP, IGMP messages 
are also carried as data portion of the IP datagrams and it forms an integral 
part of IP. The Figure 2.4, illustrates this, IGMP is therefore required to 
be implemented on all machines (hosts and routers) that participate in the 
IP multicast. The overview and implementation are outlined in the standard 
documented by S. Deorfng <(19). Tliis has been included in Appendix A 
for the sake of completeness. The use of this protocol is illustrated in the next 
chapter. 
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Chapter 3 


IP Multicast Routing 


Iq Chapter 2, the host capability for multicasting was studied. The other ma- 
jor enhancement needed at the network level to allow hosts to execute group 
based appUcations, is the routing of the multicast packets generated by these 
applications Deering [9] has proposed several algorithms for routing of mul- 
ticast datagrams iii internetworks and extended LANs The goal is to design 
multicast routing algorithms, which produce low-delay routes across the net- 
work. These algorithms have been proposed as extensions to different styles of 
umcfist routing, such as the distance- vector and link -state routing, commonly 
used in internetworks. There is as yet no standard for multicast routing in 
Internet Experimental implementations are available for the distance-vector 
style multicahit louting (DVMRP) [18] and link-state multicast routing (MO- 
SPF) MOSPF is a multicast routing protocol derived from the Open Shortest 
Path Fust (OSPF) (20) routing protocol In this project we have used the 
experimental implementation based on the distance-vector multicast routing 
(DVMRP), which is described in detail below The next generation multicast 
routers would probably implement the MOSPF protocol due to the use of 
the OSPF algorithm as the new Interior Gateway Protocol (IGP) instead of 
the present IGP, which is a distance vector style protocol. The DVMRP as 
mentioned earlier, is derived from Routing Information Protocol (RIP) [17|. 
RIP is briefly described in the next section for better understanding of the 
DVMRP 

3.1 Routing Information Protocol - Overview 

As described by Hedrick [17], RIP is one of the most widely used Interior 
Gateway Protocols, and is popularly known by the name of a piogram that 
implements it Touted The routed software was originally designed at the Uni- 
versity of California at Berkeley to provide consistent routing and reachability 
information among machines on their local notwoiks The RIP protocol is 
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an impk-mciifarion of the DcUman-Foid [4] distance- vot tor Loiiting algorithm 
within a single autonomous system in the IP-bascd Inteinot It is intended 
to allow hosts and gateways to excliange information for computing routes 
tluoitgh an IP network Each paiticipating entity in the RIP inns the routed 
piocess that sends and receives the RIP routing messages In the RIP, there is 
a provision to allow passive lUP processes A passive RIP incmber does not 
send out any messages, howevei it listens to RIP updates iii uider to moiutoi 
local gateways and to keep its internal routing tables updated All gateways 
should implement active RIP processes (i e , send and receive routing mes- 
sages) for dynamic routing The Bellman-Ford Routing is briefly described 
below. 

3.1.1 Distance- Vector (Bellman-Ford) routing 

The idea behind the vector-distance algoiitlun to piopogate loutmg informa- 
tion is as follows. 

• Each gateway begins with a set of routes for those netwoiks to which 
it attaches. This set is kept in the form of a table, wheie each entry 
identifies a destination network and gives the distance to that network 
from the gateway, measiucd in hops 

• Periodically, each gateway sends a copy of its i outing table to any other 
gateway, it can directly reach. 

• When a route report arrives at gateway K, (see Figure 3 1) from gateway 
J, K examines the set of destinations reported along with the distance 
to each. If J knows a shorter route to reach a particular destination, or, 
if J lists a destination that K does not have in its routing table, or if 
K currently routes to a destination through J and J’s distance to that 
destnation has changed, K replaces its table entry For example, Figure 
3 2 shows an existing table in the gateway K, and an update mo.ssage 
horn another gateway, J. 

• When K updates an entry based on J’s route report, for reported di-stanco 
of N to a destination, K updates the distance field for that destination 
to N-f-1 (the distance to reach the destination from J plii.s the distance 
to reach J from K), 

In the next section a vii.:tancc-vector style multicast routing algorithm as 
pioposed by Deering [9] is described. For multicast datagiam foi wauling, 
moie state information about a destination than just the distance Is required. 
This makes the implementation of distance vector based multicast routing 
algorithms more complex than the unicast implementation 
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Figure 3 1 Route Reporting in Distance- Vector Algorithm 

3.2 Distance- Vector Style Multicast Routing 
Algorithm 

According to Deenng, a straight-forward way to support multicasting in a 
distance-vector routing environment would be to compute a single spanning 
tree across all of the links and then use some multicast foi warding algorithm 
to forward multicast datagrams. In a general topology that provides alternate 
paths, no single spanning tree provides minimum-delay routes/rorn all senders 
to all sets of multicast groups The multicast routing algorithm proposed by 
Deering is based on the following observations : 

• To achieve the goal of low-delay multicasting, it is lequired that the mul- 
ticast packet be delivered along the shortest path tioC|fiom the son<lor 
to the mernbois of the multicast group 
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Figure 3 2 Routing Update at Gateway K 

• There is potentially a different shortest-path tree from every sender 
to every multicast group. However, every shorte.^t path multicast tree 
rooted at a given sender is a subtree of a single shortest path broadcast 
tree rooted at the sender. 

Deenng has modified the Reverse Path Forwarding algorithm by Dalai and 
Metcalfe [8), to produce low delay routes from a sender S to members of group 
G on the nctwoik. 

3.2.1 Reverse path forwarding 

The basic Reverse Path Forwarding algorithm (RPF) is as follows; 

A broadc.ist packet originating at source S is foi warded by the 
router, if and only if it arrives via the shorte.st path from the 
router back to S. The router forwiiid.s tlie pai ket to all incident 
links except the one on which the packet arrived. In networks, 
wliere tlie length of each path is the same in both directions 
(for ('xanii)lc when using liop counts to rncasiiic lengths), tlii.s 
algorithm lesults in a shoitest path broadcast to all links 
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As desciibcd, leveise path forwarding accomplishes a broadcast To use 
it for multicasting, a set of internet multicast addresses that can be used as 
packet destinations, have to be specified Then, the reverse path forwarding 
can be peifoimcd on all packets destinated to such addresses. Hosts choose 
which group they wish to belong to, and discard all arriving packets addressed 
to any other group, 

3.2.2 Refinements to the RPP algorithm : TRPB 

A major drawback of the basic RPF algorithm is that any single broadcast 
packet may be transmitted more than once across a link subject to the number 
of routes that share the link. This is due to the forwarding strategy, of flooding 
a packet out all links other than its arriving link, whether or not all the links 
are part of the shortest path tree, rooted at the sender Two refinements have 
been proposed. 

• To eliminate the duplicate broadcast packets generated by the RPF al- 
gorithm, it is necessary for each router to identify which of its links are 
child links in the shortest reverse path tree rooted at any given source S. 
A link is a child to a router X, if X is the next-hop address in the shortest 
path back to the sender S. Then, when a broadcast packet originating 
at S arrives via the shortest path back to S, the router forwards it to 
only the child links for S. To discover tlie child links, Dcering (9] has 
proposed a technique involving identification of a single parent router 
for each link, relative to each possible source S. The parent is the one 
with minimum distance to S. This is best understood with the following 
example illustrated in Figure 3.3, 

Here two louters X and Y are attached to LAN A and router Z is con- 
nected to a leaf LAN B. The dotted line represents the shortest path 
from X and Y to S, with the associated metric Thus router X is 5 hop 
counts away from S, distance from Y to S is 6 and that from Z to S is 
also 6 

In the basic RPF algorithm, both X and Y receive a broadcast from 
S over their shortest path links to S and both of them forward a copy 
to LAN A. Therefore any hosts attached to A receive two copies of all 
packets broadcast from S. Router Z will however, forward only one of the 
copies, the one from X, onto LAN B because X is the next hop-address 
for S. 

The Parent selection technique works as follows; 

All thice louteis X, Y and Z periodically .send distanre-vcrtor routing 
packets across LAN A, reporting their distance to every destination. 
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Figure 3 3 TRPB An Example 

FVorn these packets, each of them learns that X has the shoitcst distance 
to S. Therefore, only X adopts LAN A as a child link, relative to S, and 
Y no longer forwards superfluous broadcasts from S onto LAN A 

This parent-selection technique requires one additional field, Children 
to be added to each routing table entry. Children is bit-map with one 
bit for each incident link. The bit for link 1 in the entry for destination 
is set to 1 if 1 is ciuld link of this router for broadcasts originating at 
destination. 

• In case of extended LANs, it is desirable to conserve netwoik and router 
sources by sending multicast packets only where they ai’e wanted. Thi.s 
requires that, hosts inform the routers of their group member sliips Thus 
to provide shoitcst path multicast delivery from source S to mcrnhcis of 
group G, the shoite.st-path broadcast tice rooted at S must be pinned 
back to reach only as far as those links that have members of G. 

For a router to forgo forwarding a multicast packet, over a leaf link that 
has no group rnernbeis, the router must be able to 

- identify leaves and 
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- di'toi't gioiij) monibeislup 

Leaf links aie those child links that no otlier router uses to leacli S. 

Refeiring to Figiiie 3.3, LAN B is an example of a loaf link foi the broad- 
cast tree rooted at S I the routers periodically send a packet on each 
of its Imk^ advertising that link is the next-hop to these destinations. 
Then the parent routers of those links can tell whether or not the links 
are leaves for each possible destination. 

In the earlier example, router Z would periodically send a packet on 
LAN A saying this link ts my next hop to S Hence router X, the 
patent of LAN A would leain that LAN A is not a leaf, relative to S 
In the routing tables, another bit-map field, leaves is added to each 
entry, identifying which of the children links are leaf links. The next 
step is to identify whether or not the members of a given group exist on 
those leaves To do this, the hosts periodically report their memberships, 
using local multicast The routers on the local network keep a list, one 
for each incident link, of the groups present on that link 

The reverse path forwarding algoritlim now becomes 


IF a multicast packet from S to G arrives from 
the next-hop address for S, 

Forward a copy out all child links for S 
except 

The leaf links which have no memhers of G. 

In the next section the implementation of the multicast routing protocol 
as described by Waitzman et a/[18] is discussed This software is distributed 
freely, over the Internet, and has been used for the MBONE implementation 
on the IIT Kanpur LAN, 


3.3 DVMRP - Distance Vector Multicast Ro- 
uting Protocol 

Waitzman et af[18) have detailed the implementation of a distance vector 
style routing protocol (DVMRP) for routing multicast datagrams ba,scd on 
Deering’s algoritlun de.sciibed above. This protocol is derived fiom RIP and 
implements the TRPB algorithm for forwarding multicast packets. DVMRP 
combines features of RIP with TRPB It is an Interior Gateway Proto- 
col suitable for use within an autonomous sy.stern, but riot between diffoLeut 



autonomous systt'iiis It’s cuitent impleineiitatioii doos nc;t support routing 
non-multicast datagrams, so, a router that loutes multicast and uuitast data- 
grams, needs to run two routing processes, one for the multicast and the other 
for the normal unicast and broadcast datagiams The multicast foi warding 
algorithm rociuiies the building of trees based on routing information In ad- 
dition to the implementation of the TRPB algorithm for datagram forwarding 
this implementation provides a tunneling mechanism to travel se networks 
that do not support multicasting Some of the implementation issues of the 
DVMRP aie discussed in the following sections 

3.3.1 RIP vs DVMRP 

The tree building piocess for datagram forwarding needs more state infor- 
mation that RIP IS designed to provide. The most important difference in 
the two algorithms is at a configuration level. RIP Is configured in terms of 
routing and forwarding datagiams to a particular destmation. Whereas the 
DVMRP aims at keeping track of the return paths to the soui'ce of the multi- 
cast datagrrams. Thus in the DVMRP context, datagrams are not forwarded 
to the destination of the (distance, destination) pair in the routing mes.s’agp, 
but originate fiom them. This makes DVMRP implementation much more 
complex as compared to RIP 

3.3.2 Format of DVMRP datagrams 
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Figure 3.4: Fixed Length IGMP Header of DVMRP Messages 

DVMRP uses the Internet Group Management Protocol (IGMP) to exchange 
routing datagrams. DVMRP datagrams are compo.scd of two portions : a 
small, fixed length IGMP header and a stream of tagged data The fixed 
length IGMP header of DVMRP message is as .shown in Figiiic 3 4 The 
types of DVMRP inos,sagos are as follows: 

1. Response ; piovidos routes to destinations 
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2 Request KHiuests lontes to destinations 

3 Non-membership report(s) 

4 Non-membeiship cancellation 

The checksum is 16-bit one’s complement of one’s complement sum of the 
entire message, excluding the IP header The element of the stream of tagged 
data are called commands and are multiple of 16 bits The commands are 
organised as an eight bit command numeric code, with atleast an 8-bit data 
portion A message that has an error in it will be discarded at the point in 
prosessmg, where the error is detected. The length of the DVMRP message is 
limited to 512 bytes, excluding the IP header The supported commands are 
included in the appendix B 

3.3.3 The DVMRP tunnel mechanism 

DVMRP defines a method for sending datagiaiiis between unites seperated 
by gateways that do not support multicasting routing A tunnel provides a 
virtual path between two multicast routeis. 



Figure 3.5: Tunnel Configuration - An Example 
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Tunm^ling has boon considorod as tiaiisitional rncohaiiism To understand 
the tunneling moohaiiism, consider the nctwoik in Figuie 3.r> 

Host HI IS on LAN A and Host H2 is on LAN E Routers X and Y are 
multicast routcis and accept multicast IP datagiams Routers V and W are 
routeis wiiich do not support multicast loutingjand theiefore would discaid 
multicast IP packets if the destination address is a class D internet address 
To piovide the viitual link between X and Y for IP multicast datagrams to 
flow from X to Y a tunnel is defined between the routers X and Y. A tunnel 
has the following parameters associated with it • 

• local end point: the local host’s internet address 

• remote end point, the remote host’s internet address 

• metric the cost of sending the datagram via the tunnel 

• thieshold the minimum ttl value that the datagram should have for 
foi warding thus datagram acioss the tunnel 

A tunnel defined in X, from X to Y would have the configuration 

• local end point = Internet addiess of the network interface of X con- 
nected to V (Ix). 

• remote end point = Internet address of the network interface of Y con- 
nected to W (ly) 

• metric = 3 

• thieshold >=3 

A similar tunnel would have to be configured ui Y with the local and 
remote end points defined appropriately. 

This tunnel makes the above network configuration look as shown in Figure 
3.6. The routers at each end of the tunnel need only agree upon the local and 
remote end [mint. The metric and threshold should be .so chosen as closely 
appoximate the no of intermediate gateways between end points. Tunneling 
is done with a weakly encapsulated normal multicasted datagram The weak 
encapsulation uses a two element IP Loose Source Route option. Recent im- 
plementations do tunneling using strong encapsulation, i.c prepending entire 
new IPhcador. 

The idea behind the source route IP option is that, it provides a mech- 
anism for the sender, to dictate a path through the Internet. In the loose 
source route foiin, a sequence of IP addresses are included whicli specify the 
route Multiple network hops arc alloweil hetweou succi'.ssive addie.s.s on the 
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Figure 3.6' A Virtual Network Coafiguratioii 

list. The format of the IP LSR is shown in Figure 3 7. The code field contains 
the option no. and class The length field specifics the total option length 
including the first 3 octets The pointer specifies the offset within the option, 
pointing to the first address. Routing messages are earned through tunnels, 
but a route is not created for the tunnel. The routing messages are sent as 
unicast datagrams directly to the lemote end-point without using the IP LSR 
option 

For the tunnel mechanism to work properly, the intermediate gateways 
should ignoie the LSR option and the remote-end point should detect the 
LSR option The former is possible because, when an intei mediate gateways 
receives a datagram, it examines the destination address. This address will not 
match its own address, and therefore, the receiving gateway will not examine 
the LSR option, but pass on this packet to the next gateway in the path to the 
destination When the remote end point receives the datagram, the datagram 
destination address matches its own address. It then looks at the next LSRR 
option address, since the source route has not exhausted. That address is a 
multicast address Because the hosts are not allowed to put multicast addicss 
in source loutos, the gateway can infer that the LSRR is for tunneling. In the 
following section some iinplcineutatiun re<iuiiem(*iits of the touting algorithm 
for routing of multicast packets are studied. 

3.3.4 Virtual Interfaces and Virtual Networks 

While the DVMRP can express routes to hosts, the foi warding and routing 
ulgonthin only sii[)poi’t network and sulmetwork loiitiiig 'lb iiit’oriiorate the 
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Figuie 3.7: IP LSRR Option 

tunnels as valid network interfaces, the concept of virtual interfaces and virtual 
networks has been introduced. A physical interface, such as an Ethernet 
card or a tunnel local-end point, is termed as a virtual interface in this* 
specification. A route to destination is through a virtual interface. A Virtual 
Network refers to a physical network or tunnel, however, routes only refeience 
physical networks The TRPB algorithm forwards multicast datagrams by 
computing the shortest paoh tiee from the source (a physical network) to all 
possible destinations (member of a group). Each multicast router determines 
its place in the tree, relative to particular source, and also determines which of 
its virtual intei faces are in the shortest path tree. The datagram is forwarded 
to all child virtual interfaces^ except those leaf interfaces which have no 
members of the group. The building of the tree, discovering membership and 
leaf interfaces is done by exchange of routing messages with neighbouring 
routes The state is maintained in a routing table containing one entiy, for 
each leachable destination, over the viitual interface 

3.3.5 Determining leaf interfaces 

If any neighboring router, considers a given viitual iietwoik in the path to a 
given destination, then the viitual network Ls not a leaf. Otherwise, it i.s a 
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leaf This is a voting function If a loute, with a motiic poisoned by split 
honzon processing [17], is sent by some router, then that router vises that 
virtual network as the uptree path for that route (i e , that louter votes that 
the viitual iietwoik is not a leaf lolative to the route’s destination) Since 
the number of routcis on a virtual netwoik is dynamic, and snice all received 
routing updates aie not kept by routers, some heuristic mechanism is needed 
to detoiinine when a network is a leaf. DVMRP samples the louting updates 
on a virtual interface while a hold down timer is running, which is for a 
time period of LEAF.TIMEOUT seconds. There is one hold-down timer per 
virtual interface If a loute vs received with a metric poisoned by split horizon 
processing [17] while the hold-down timer is runmng, or at any other time, 
then the appropriate virtual interface for that route is spoiled- it is not a leaf 
For every route, any virtual interface that was not spoiled by the time the 
hold-down timei expires is considered a leaf. 

3.3.6 Routing table entry 

A loute entry should have the following in it* 

1. Destination address (a source of multicast datagrams) * 

2 Subnet mask of the destination address * 

3 Next-hop 1 outer to the destination address 

4. Virtual interface to the next-hop router * . ' - 

5 List of cluld virtual interfaces * 

6. List of leaf virtual interfaces * 

7. A dominant router address for each virtual interface 

8. A subordinate router address for eacli virtual interface 

9. Timer 

10. Sot of flags that indicate the state of the entry 

11. Metric 

12. Infinity 

The lines that aie marked with * indicate fields that are dlioctly used 
by the forv/arding algoiithm. The lists of cliild and leaf interfaces can be 
implemented as bitmaps. 



3.3.7 Thresholds 

One concept in Internet Multicasting is to use thresholds to restrict which 
multicast datagrams exit a network. Multicast routers on the edge of a sub- 
netted network or autonomous system may require a datagram to have large 
TTL to exit a network. This mechanism keeps most multicast datagrams 
within the network, reducing external traffic. An application that wants to 
multicast outside of its network, would need to give its multicast datagrams 
at least a TTL of the sura of the threshold and the distance to the edge of 
the network (assuming TTL is used as a hop count within the network). A 
configuration option, should allow specifying the threshold, for both physical 
interfaces and tunnels 

3.3.8 Sending routing messages 

DVMRP routing messages can be used for three basic purposes: 

• to periodically supply all routing information, 

• to gratuitously supply routing information for recently changed routes 
or 

• supply some or all routes in response to a request. 

Routing messages sent to physical interfaces should have an IP TTL of 
1. A number of timeouts and rates are used by the routing and forwarding 
algorithms. The values for these are given in appendix B The rules for when - - 
to send routing messages are given in chapter 4. 

3.3.9 Receiving routing messages 

A router should know the virtual interface that a routing message arrived on. 
Because the routing message may be addressed to the all-multicast-routers IP 
address, and because of tunnels, the incoming interface cannot be identified 
merely by examining the message’s IP destination address The route report 
processing is discussed in detail in Appendix B. 

3.3.10 Discovering neighbours 

Neighbours are discovered at startup dui’ing initialization when neighbour 
probe packets are sent over all multicast capable interfaces of the router. Tun- 
nel remote-end points are also neighbours. A list of the neighboring multicast 
routers on every attached network should be kept. The information can be de- 
rived by the DVMRP routing messages that are received A neighbor that has 
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not been heard fiom in NEIGHBOR.TIMEOUT seconds should be considered 
to be down 


3.3.11 Local group memberships 

A multicast router must keep track of group memberships on the multicast- 
capable networks attached to it, as required in the IGMP implementation. 
Every QUERY -RATE seconds an IGMP membership request should be sent 
to the All Hosts multicast address (224.0.0.1) on each network by a des- 
ignated router on that network. The IGMP membership request will cause 
hosts to respond with IGMP membership reports after a small delay Hosts 
will send the report for a group to the group's multicast address The mem- 
bership requests should have an IP TTL of 1 

The routers on a network elect a single router to send the queries. The 
designated router is the router with the lowest IP address on that network. 
Upon startup a router considers itself to be the designated router until it 
learns (through routing messages) of a router with a lower address To learn 
about the group members present on a network at startup, a router should 
multicast a number of membership requests, seperated by a small delay The 
authors suggest sending tliree requests seperated by four seconds. 

The multicast router must receive all datagrams sent to all multicast ad- 
dresses, Upon receiving an IGMP membership report for a group fiom an 
interface, it must either record the existence of that group on the interface 
and record the time, or update the time if the group is already recorded The 
recorded group memberships must be timed-out. If a group member report is 
not received for a recorded group after MEMBERSHIP-TIMEOUT seconds, 
the recorded group should be deleted. 

Several issues such as the time-out values and threshold depend on the 
network span and bandwidth 

In the next chapter, the Multicast Backbone implementation using the IP 
multicast, IGMP and DVMRP, is discussed. 
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Chapter 4 


IP Multicast Backbone 
Implementation Details 


In this chapter the Internet Engineering Task Force (IETF) Multicast Back- 
bone (MBONE) implementation is first studied. Next, the IP multicast back- 
bone implementation on the Campus network is presented Some of the LAN 
enhancements for group communications have been demonstrated using pub- 
lic domain softwaie avmlable over the Internet The concluding part of this 
chaptei gives the details of tins software used for demonstration purpose 


4.1 The IETF Multicast Backbone Configura- 
tion 

The MBONE was designed and configured by the IETF to support multicast 
transmission of IP datagrams carrying live audio and video from the IETF 
meeting sites to remote destinations over the world. It has been envisaged as 
an IP-multicast testbed to support continued experimentation between var- 
ious Internet sites. The MBONE experiment began as a co-operative effort 
between a few Internet sites and later became very popular among the Internet 
community. Being an experimental implornontation theie is very little docti- 
inentatkm and most of the issues related to tlic MDONE liave been e.xplaliicd 
in MBONE - Most Frequently Asked Questions, (FAQ)(G] 

4.1.1 MBONE - A virtual network 

The MDONE is a virtual notwoik layered on top of parts of the existing 
physical Internet, configured to support the routing of rniiltica.st packets to 
1 emote clestiiiatioiis on the Internet. The iietwoik is virtual iii the .si'ii.sc that, 
there is no sopeiate pliy.sical network to carry the multicast pa<‘ket.s Portioii.s 
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of the existins nofwuik have boon conH^urod for inultu astin{r without any 
physical changes to the netwoik 

The MBONE consists of islands or networks which suppoit multicast, 
connected by virtual links called tunnels (see Chapter 2 for the tunnel defini- 
tions) The tunnel cnd-points are typically workstation class machines, having 
operating system support for IP multicast, and runmng the Distance Vector 
Multiciist Routing DVMRP daemon, process mrouted 



Figuie 4 1: A Simple MBONE Configuration 

A simplified MBONE configuration is as shown in Figute 4,1. The tunnel 
mechanism is implemented by either using an IP LSRR option or by IP en- 
capsulation. The IP encapsulataion method adds an extra IP header with 
the source and destination address of the tunnel end-points to every multicast 
IP datagram Tlie IP LSRR option has air dy boon described in Chapter 
3. Due to the wide geographic span of MBONE, the do.signei.s have given a 
careful thought in planning the MBONE topology acioss the world. An cffoit 






luis been niado to minimise the traffic between continents The detailed de- 
scription with the hardwaje and softwaie requueinents to join the MBONE, 
are given in the [Oj A few of the iiiteiesting issues involved in the MBONE 
configuration aie discussed below 

4.1.2 Topology of MBONE 

Within a continent, the topology of MBONE is a combination of mesh and 
star The regional and backbone networks are linked by a mesh of tunnels to 
form the topmost level of the MBONE heirarchy The tunnels are configured 
among machines executing the multicast routing daemon mTouted. These 
machines are piimaiily located at the lutei connection points of the backbone 
and the regional networks. For robustness, redundant tunnels with higher 
metric are also configured. 

Each of tiic regional network has a star hierarchy hanging off its node 
of the mesh, to fan out and connect customer networks. The setup of the 
MBONE toplogy has been through continued co-operative efforts among the 
participants , At the topmost level is the configuration of the mesh winch i.s 
managed by the IETF thiough four regional centres These four regions are 
identified on a geographical basis viz 

1 North America 

2. Em ope 

3. Austialia 

4. Others 

The IETF has set up soperate mailing lists for each of these regions to 
co-ordinate customer network connections to the MBONE 

Another important issue in the MBONE design is the bandwidth consider- 
ations, and support for real-time traffic. The MBONE design considerations 
for these are given below. 

4.1.3 Traffic levels on the MBONE 

The primary aim of the MBONE set-up was to carry live audio and video. 
With a data rate of 64kb/s FCM encoded audio and 64 kb/s - 128 kb/s H.2G1 
[5] compatible video, a design bandwidth of 500 Kbps was chosen. During the 
IETF traiLsniissions a traffic level of 100-300 Kbp.s was aiiticijiated. At tlio 
peak level, 5 simultaneous conversations were expected. Theiefoie, the design 
bandwidth of 500 Kbps was justified. 
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width needs to bo iiuiltiplied by the number of tunnels passing over any given 
link For this loasoii, each multicast louter, is configuicd to connect a maxi- 
mum of 10 links, and the topology of MBONE is so designed as to configure 
at most two tunnels over any intercontinental link It is expected that most 
of the MBONE nodes connect with lines of atleast T1 {1,544Mbps) speed. 

To restrict the traffic over slower speed links, each tunnel has an associated 
threshold against which the IP packet’s time to live (TTL) field is compared. 
Higher bandwidth sources such as video transmit with smaller ttl so that 
they can bo blocked fiom tiaiisinitting over luwei speed links, wlicieas lowei 
bandwidth sources such as compressed audio are allowed to pass through 

The threshold is the minimum TTL value required for a multicast data- 
gram to be forwarded to the given interface or tunnel. For example, video 
applications generate IP packets with a TTL of 127. However, if the tunnel is 
configured with a threshold greater than 127, say 128, these packets will be 
dropped 

At piescMit the nussh configuiation is completely handlod thinugh co-operat- 
ive efforts on the part of network providers within each region as well as at 
higher levels of the MBONE hierarchy. Until a mechamsm of MBONE config- 
uration using some network management piotocols is available, the network 
providers and the customer networks have to interact to provide the MBONE 
connections 

In this piojcct, we have emulated MBONE essentially to study the various 
issues involved in providing group communications sci vices over the Campus 
netwoik. The Campus network is an extended LAN.topolgy Three host 
machines on three diffeient subnets have been coiifiguied to run the mrouted. 
In the next section, the IIT Kanpur LAN configux’dtion is studied. 


4.2 IIT Kanpur Campus LAN Architecture 

The IITK LAN consists of several Ethernet segments connected to a thick 
ethernet backbone The LAN configuration is as shown in the Figure 4.2. 

The segments are interconnected by a mix of IP routers, bridges (both de- 
veloped at IIT Kanpur) and repeaters. The LAN covers the eiithc academic 
area. A few sites aie also connected through the digital multikey telephone 
(DMKT)-ba.sed serial <iata links. This LAN is connected through a CISCO 
router to the ERNET WAN via two serial ports and modems to DOE Delhi 
and IIT Khaiaglipiir. Outside e-mail luseis aic connected via dialup modem.s 
to a gateway system. The IIT Kanpur Campus network site is a part of tlie 
Educational and Research Network (ERNET). The ERNET has been allo- 
cated a single IP cla.ss B network number (144.16). Each ERNET site has 
been alloted 32 class D subnet numbers. The IITK irsos IP subnets rang- 













ing from 144 16 160 xxx to 144 16 191 xxx Presently, 4 clciss B IP subnets 
are being used m the campus network These are the ERNET backbone 
(144.16 161 xxx), CSENET (144 16.162 xxx), CCNET (144 16 163.xxx) and 
ACESNET/EENET (144.16 160 xxx) The ERNET backbone connects the 
other three subnets through IP routers It is planned to upgrade the routers 
to support class C level filtering so that overall management of the address 
space is simplified. 

With the above configuration of the Campus network, given in Figure 4 3 
is the desired MBONE virtual network on the campus LAN. 



•" Router “ Tunnel 



Figure 4.3: Desired IITK-MBONE Netwoik 

For the trial implementation three machines have been chosen on three 
different subnets and linked by tunnels. The details of the trial configuration 
are given in the following section. 
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4.3 Configuration of MBONE on Campus LAN 



144 16 161 ERNET backbone 


Figure 4 4. IITK-MBONE Experimental Setup 

This configuration provides multicast IP datagram transmission and routing 
support for hosts on the CSENET, EENET and ERNET backbone. The IP 
multicast routers aie configui'ed as shown in Figure 4 4, and the coiTcsponding 
physical intei connection is as shown in Figure 4,5. (jyan is a SunSPARClO ma- 
dune with suu4ni architecture and SunOS 4 1.3 operating system, on the sub- 
net 144 16.160. Tliis machine acts as a multicast router for the ACES/EENET 
subnet. The host transport is a machine on the subnet 144.16 161 and is aLso 
a SunSPARClO witii same configuration as gyan It rontc.s all the multi- 
cast traffic to/frorn the ERNET backbone. The third machine cslO is a 
SunSPARCl-t- with sun3 architecture and sunOS 4.0 opc’iating .sy.stem, Thi.s 
machine is configured to route the multicast traffic to/fioin the CSENET suV>- 
nct The foatnri'S of the Carnpus-MDONE implerru'iitation aic given iii ilct.iil 
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Figure 4 5 IITK-MBONE The Corresponding Physical Interconnections 

4.3.1 Features of the IITK-MBONE 

The charcteristic features of the IITK-MBONE are as follows’ 

1 No modification made to the existing IP routers in the LAN, These 
route the unicast packets as before. The existing IP routers implement 
passive RIP and are being upgraded to lun the active RIP processes 
These 1 outers allow loose source routing of the IP datagrams. The mul- 
ticast routers send the multicast datagrams using the IP LSRR m by IP 
encapsulation to the remote ond-poiiits 

2, Typically, a router has atleast two physical netwoik interfaces. In addi- 
tion, for multicas’t routing, the concept of a viitiial interface (see sectuni 




3 3 4) allows a router to build one oi nioie tuimolb ovoi the same physical 
mteiface These tunnels act as links to different subnets and therefore 
for non-trivial multicast routing the numbei of virtual network inter- 
faces and the physical network intci faces must be atloast two To allow 
hosts with a single physical interface to perform the routing function, 
the multicast routing daemon has been modified to biuld two virtual 
interfaces over the same physical interface. 

3. Host machines cslO, gyan and transport and kasha have been con- 
figured to also support host IP multicast, confoiming to the level 2 IP 
multicast as specified in the standard [19] for IP multicast These ma- 
chines can send and leceive IP multicast datagrams 

4. The IP multicast hosts and routers run the Internet Group Management 
Protocol (IGMP) The routing updates and membership lepoits are sent 
using the IGMP message formats as specified in [19] 

5. The public domain software sd for multicast session creation and man- 
agement has been ported on all IP multicast hosts, to demonstrate some 
featuies of the MDONE 

4.4 The Implementation Details 

The implementation of the IP multicast and multicast routing, has been done 
m two stages 

• Host extensions for IP multicast 

• Multicast routing daemon mrouted implementation 

The IP multicast host extensions were available fiom anonymous ftp server 
on the host gregorio. Stanford. edu in the directory vmtp-ip This software 
when compiled, modifies the kernel to support IP multicast To understand 
the IP multicast implementation, m the UNIX domain, a brief summary of 
the internal structure of the network subsystem provided by the UNIX en- 
vironment is included in Appendix C. More details of the Unix Networking 
Environment can be found in [13] or [24]. 

The modifications made to the network interface module, and the comrnu- 
uicatiou modules of the iietwoik subsytem m oadi of the hosts on wlin-h IP 
multicast capability has been added are explained below. 
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4.4.1 The network interface 

The state of the nctwoik interface and ceitaiii externally visible characteristics 
are stoicd in the Interface Flags field as shown in Table 4 1. These flags are 
set by the system with loctl [13] requests The modifications made in the 
network interface for multicasting are as follows 

• The flag IFFJ4ULTICAST is set using the attach routine at boot time. 

• The driver is configured to handle changes in the IFF_PROMISC and 
IFFJRJLTI interface flags These are needed when co-ordinating the 
address filter list of the interface 

• Two new ioctls SIOCADDMULTI and SIOCDELMULTI are added, to add 
or delete Imk-levcl (eg. Ethernet) multicast addresses accepted by a 
particular intei face The address to be added or deleted is passed as a 
sockaddr structure of family AF.UNSPEC within the standard ifreq 
structure These ioctls can be used by protocols other than IP and 
requiie supeiusei privileges. 

• For Ethernets, the function ether.addmultiO and ether_delinultiC) 
axe added, which can be used to maintain a list of multicast addresses. 
Macros ETHER_FIRSTJ4ULTI() and ETHERJIEXT-HULTK) are added, to 
scan the list when updating the address filter. 


NETWORK INTERFACE FLAGS 

FLAGS 

Descnptloa 

IFF.UP 

Interface \s available for use 

IFP_BROADCAST 

broadcast is supported 

IFFJ)EBUG 

enable debugging In the interface software 

[FF_LOOPBACK 

this IS a software loopback interface 

IFF_NOTRAILERS 

interface should noi use traiicf encapa 

IFF.RUNNING 

interface resources are allocated 

IFP_NOARP 

Interface should not use ARP protoc 

IFF.POINTTOPOINT 

Interface is a point-to-pomt link 
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These modifications aie iiKlepeudont of the iietwoik layer piotocol The 
TCP/IP cornimiiiK atioii protocol specific modifications can be best iiiidci- 
stood on the basis of tlie model of the liost IP implementation as shown in 
Figure 2 4 

4.4.2 Extensions to the IP service interface 

The interface from the socket routines to the IP is through user requests 
and control output routines defined in the IP protocol switcli table This 
implementation supports IP multicast on raw sockets and datagram sockets 
of the AFJNET family The raw socket allows privileged users direct access 
to the IP protocol. 

The details of UDP socket SOCK.DGRAM interface are given m |24J ihe 
IP service interface has been modified to provide three new socket options, for 
specifying parameters m the IP header of the multicast datagram. These are 
described below ■ 

• IP-MULTICAST.TTL . 

This option ha.s boon addod to limit tho scope of tlio multicast packet 
to a span decided by the ttl field of the datagiaiii header Thi.s liiiuts 
uimecessaiy transmissions to networks beyond the scope of the multicast 
group Using this option the ttl field in the IP header can be set from 
0 to 255, in order to control the scope of the multicast 


u_char ttl; 

setsockoptCsock, IPPROTO.IP, IP_MULTICAST_TTL, 

&ttl, sizeof (ttl)) ; 

Multicast datagrams with a ttl of 0 are not transmitted on any subnet, 
but only delivered locally 

• IPJiULTICAST.IF 

Each multicast transmission is sent from a single network interface set 
to default by the network administrator Tliis socket option allows over- 
riding the default multicast interface for subsequent transmissions from 
a given socket 


struct in_addr addr; 

setsockoptCsock, IPPROTO.IP, IP.MULTICAST.IF, 

addr, sizeof (addr)) ; 
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whore addr is the local IP ruldioss of the dcsitod outgoing iiitoifnce 
To revolt to tlio default, the addr IHADDR^ANY .shoiiUl be used with 
the same socket option The local IP address of a paiticiilar interface 
can be obtained using the SIOCGIFCONF loctl To determine if an 
interface supports multicasting, the interface flags can be fetched via 
the SIQCGIFFLAGS loctl to check the IFFJ1ULTICAST flag 

IP_MULTICAST_LOOP. 

If a multicast datagram is sent to a group to which the sending host 
itself belongs (on that outgoing interface), a copy of the datagram is, by 
default looped back by the IP layer for local delivery To give the sender 
explicit control over whether subsequent datagrams are looped back 


u_char loop; 

setsockopt(sock, IPPROTO.IP, IP_MULTICAST_LOOP , 
loop, sizeof (loop) ) ; 

where loop =1 to enable loopback, loop =0 to disable loopback. 

Tills option provides a performance benefit for applications that may 
have, no more than one instance on a single (such as a router or a mail 
daemon), by eliminating the overhead of receiving their own transmis- 
sions. It should not be used by applications for which there may be more 
than one instance on a single host (such as a conferencing program) or 
for which the sender does not belong to the destination gioup (such as 
a time querying program). 

IP_ADD_MEMBERSHIP 

Before a host can receive IP multicast datagrams, it must become a 
member of one or more IP multicast groups. A process can ask the host 
to join a multicast group using this socket option : 


struct ip.mreq mreq; 

setsockoptCsock, IPPROTO^IP, IP_ADD_MEMBERSHIP , 

mreq, sizeof (mreq) ) ; 

where mreq is the following stiiictiire ‘ 

struct ip_mreq { 

struct in_addr imr.multiaddr ; 
struct ln_addr imr.interface; 

} 



Every ineinboislup is associated witli a single nitt'itate and it is possible 
to join the same group on more than one interface To choose the default 
interface the imr.interface should be INADDR_ANY, to choose a partic- 
ular interface the amr. interface should bo the host’s local address for 
that interface. Upto IPJ1AX_MEMBERSHIPS {ciuiently 20) memberships 
may be added on a single socket. The IP soivue inteifaco invokes this 
option on the 


JoinHostGroup(group_address , interface) 

call from the upper layer 
• IPJDROPJ^EMBERSHIP 


struct ipmreq mreq; 

setsockoptCsock, IPPROTO.IP, IP.DROP.MEMBERSHIP, 

mreq, sizeof (mreq)); 

where mreq is the same structure as defined above The membership 
associated with a socket is also dropped when the socket is closed or the 
process holding the socket, is killed. More than one socket may claim 
membeisliip to a group, and therfore the host remains a member of the 
group until the last membership is dropped This option is invoked by 


LeaveHostGroup(group_address, interface) 

call from the upper layers. The membership associated with a socket 
does not necessarily determine which datagrams are received on that 
socket Incoming multicast datagrams are accepted by the kernel IP 
layer if any socket has claimed membership m the destination group 
of the IP datagram Delivery of the multicast datagram to a partcular 
socket IS based on the destination port (or protocol type, for raw .sockets), 
just as with the tmlca.st datagrams To receive multicast datagrams .sent 
to a particular port, it is necessary to bind to the local port, leaving the 
local address unspecified (i e. IN_ADDR_ANY). 

• S0_REUSEADDR 

Mote than one process may bind to the same SOCK-DGRAM UDP port if 
the bind is preceded by 
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int one = 1 ; 

setsock;opt(sock, S0L_S0CKET, SO_REUSEADDFl, 

&one,sizeof (one)) ; 

In this Ciise, every incoming multicast or broadcast UDP datagram des- 
tined to the shared port will be delivered to all the sockets bound to 
that port The SOCKJtAW does not need this option since no bind() is 
reciuircd in the raw sockets 

4.4.3 Extensions to the IP module 

To support multicasting, the IP module must be extended to recognize IP 
host group addresses when routing outgoing datgrams, 

This implementation includes the following logic 


if IP_destination is on the same local network 
or IP_destanation is a host group 

send datagram locally to IP.destination 

else 

send datagram locally to GatewayTo(IP_destanation) 

If the sending host is itself a member of the destination group, a copy of 
tlie outgoing datagiam must be looped back for local delivery unless inhibited 
by the sender. 

A check is made when sending IP datagrams, that a group address is not 
placed in the source address field on anywhere in the source routing option of 
the outgoing datagiam 

To support the reception of the multicast IP datagiam, the IP module is 
extended to maintain a list of the host gioup memberships associated with 
each network interface 

Associated with each gioup is a count of the number of members of that 
group The list of host group memberships associated with a network inter- 
face IS updated in reponse to the JoinHostGroupO or LeaveHostGroupO 
requests from upperlayer protocols. On the first request to join, and the last 
request to leave a group, the local network module is notified, so that it may 
update its multicast filter. In addition to the above changes, hosts with level 
2 confoiniaiKe to the IP inultuast staiidiud [19] imiilerneiit the liost-IGMP 
as explained in Appendix A, for informing the local multicast roiitois of its 
group mcinbei ships 



4.4.4 Extensions to the network service interface 

As expldiiied in the Section 2 3 1 of Clidpter 2, the inapiJing of the IP host 
group address to the Ethernet multicast address is done by the Nctwoik sei- 
vice inteiface Incoming local network multicast paikcts au* delivered to the 
IP module using the same Receive_Local operation as the unicast packets. 
To allow the IP module to tell the local network module, which multicas't 
packets to accept, the local network service interface Is extended to provide 
two new opeiations 


JoinLocalGroup (group. address) 

LeaveLocalGroup(group_address) 

where the group.address is an IP host group addiess. These invoke ioctl 
calls SIOCADDMULTI and SIOCDELMULTI at the link level as discussed m the 
Section 4 4.2 

To summarize, the extensions to the host IP implementation provide the 
following new options to the socket layer 

• add memberslup to a group 

• delete membership from a group 

• specify a ttl value in the multicast Ip datagram header 

• specify loopback/no loopback of the IP datagram 

• specify the interface on which to send/receive the multicast IP data- 
grams 

This implementation also incorporates the Host IGMP implementation. 

In the next section, we outline the multicast routing daemon implementa- 
tion along with the modificotions made to tailor the code for the IITKanpur 
LAN environment 


4.5 The Multicast Routing Daemon - mrouted 

Mrouted is an implementation of the Distance Vector Multicast Routing Pro- 
tocol explained m the Chapter 3, as per [18] This daemon process main- 
tains the topological knowledge via a distance vector routing protocol, upon 
which it implements a multicast forwarding algorithm called tiie Truncated 
Reverse Path Broadcast (TRPB), see section 3,2.2 

To route the multicast packets over the campus LAN and yet leave the 
existing (unicast) routers untouched, requiicd either 
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• IGMr,HObT,MEMBERSHIP.REPOaT • In response to IGMP_HOS- 
T-MEMBERSHIP QUERY, eveiy liost wluch has atloast one Kroiip, re- 
sponds with a icpoit message as per the state diagiain of IGMP (see 
Appendix A) On leccipt of the lepoit, the DVMRP router updates the 
group memberships and records or updates the time After MEMBER- 
SHIP.TIMEOUT seconds, the recorded group is deleted if not heard 
of 

The various timer values are given m the Appendix B Tiie algoritlims for 
the route report processing and the algorithm for manipulating the leaf and 
child links is included in the same 

4.5.2 Multicast packet forwarding algorithm 

The forwarding algorithm is as follows 
IF (IP TTL < 2) 

THEN CONTINUE with the next datagram, 
find the route to the source of the datagram, 

IF (no route exists) 

THEN CONTINUE with the next datagram; 

IF ( the datagram was not received on the next-hop 
virtual-interface for the route ) • 

THEN CONTINUE with the next datagram; 

IF ( the datagram is tunneled ) 

THEN reconstruct the correct source and destination 
IP add’^esses and adjust the 
IP header length; 

IF ( the datagram is destined to group 224.0.0.1 or 
224,0.0.4 ) 

THEM CONTINUE with the next datagram; 

FOR each virtual interface V 

DO IF ( V IS in the child list for the source of the 
datagram ) 

THEN IF (V is not in the leaf list of the source) 

OR (there are members of the destination 
group on V ) 
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1 dedicated machines with atleast two physical interfaces to execute the 
mrouted code or 

2 modification in the mrouted code to allow multicast hosts with a single 
physical interface to perform the routing function by building two virtual 
interfaces over a single physical interface 

The second alternative was chosen and has been implemented on gyan, 
transport and cslO. 

The umcast and multicast routing is done by two diffeioiit processes to 
route multicast packets to subnets, modifications were made to the struct- 
ure uvif .array ( this stores the complete details of every configured Virtual 
interface) in the mrouted to allow subnettmg. The changes have been done 
in the tt mrouted/config.c, mrouted/vif c, mrouted/route.c and the related 
header files. 

The next section gives a brief explanation of the DVMRP router imple- 
mentation. The details are given in [6]. Few of the implementation details are 
included in the Appendix B. 

4.5.1 DVMRP implementation 

The route propagation is done through the DVMRP route lepoits Following 
DVMRP message types are used to build the routes. 

• DVMRP JPROBE : After initialization mrouted sends query packets to 
its valid neighbours for checking their status. If the neighbour is up and 
reachable, it sends a route update to the initiating router If a neighbour 
is not heard from in NEIGHBOUR.TIMEOUT seconds, it is considered 
down by the mrouted 

• DVMRP -REPORT ; A route report with all its routing information is 
sent to nil its virtual interfaces 

1. Every FULL.UPDATE JIATE seconds . 

2 Every TRIGGERED_UPDATE_RATE seconds, whenever a route 
changes. 

3. When a DVMRP router is restarted 

4. When the DVMRP router is about to terminate execution. 

The types of IGMP messages are. 

• IGMP JHOST-MEMBERSHIP.QUERY . Every QUERY-RATE seconds 
an IGMP membership request is sent to the alLhosts.group address if 
the router is designated as querier on that network. 
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THEN ir ( IP TTL > V‘3 threshold ) 

THEN subtract 1 from the IP TTL and 
foruaxd the datagram out V; 

The routing table entiles have already been mentioned in Chapter 3 

4.6 Demonstration Set-up 

The program SESSION DIRECTORY sd which announces, creates and man- 
ages multicast sessions has been used A brief summary of sd follows 

4.6.1 Session Directory -sd 

Sd piovides’ 

• A dynamically updated list of available sessions (e g., vat audio confer- 
ences, nv or ivs video conferences, or wb whiteboard confeiences). A 
brief summary of these is given in the next section, 

• A way to join any available session(s) 

• A way to create and advertise new session (s). 

Executing sd creates an X window sd multicasts its own advertisement 
to be picked up by anyone else running sd. At the same time sd also picks up 
information about the current sessions on the network and displays them for 
for the user to paiticipate if desired The audio, video and shared X window 
(Whiteboard) programs can be invoked with the right parameters through 
sd The user can open a new session or become a member of the already 
setup sessions sd starts up the appropriate tools for the session (vat, nv, 
ivs and/or wb), that have been specified. 

When sd creates new sessions, it clioo.ses by default a unique, nonconflic- 
ting multicast addiess, port and conference ID for tlic session. Tlie user can 
choose his/hci own addiess, port or conference ID, to setup new sessions also. 
The address can bo either an IP addiess or DNS name. Port and ID must be 
integers in the range 1 to 65535. 

By default, only audio media is selected for tire session. If you want to 
announce that the conference contains video and/or a whiteboard, the choice 
has to be explicitly specified 

While creating sessions scope lets a u.scr set the multicast ttl of the .ses.sion 

Given below is a biief summary of the voice packotizei vat, and the Xll 
based tool foi shaied drawing suiface, wb (Whiteboaid), which have been used 
for the demonstration 
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• Voice Audio Tool - vat 

Vat IS an Xll-based audio teleconferencing tool which allows asers to 
conduct host-to-host or multihost audio tclecoiifoionces over an internet 
(multdiost confeiences require that the kernel support IP multicast). No 
special harilware other than a microphone is reciunod for vat - sound 
I/O IS via a Sparcstation’s built-in audio hardwaic 

Cuiiontly available audio foiinats aie 

1 pem 64Kb/s 8-bit rau-law encoded 8KHz PCM 

2 idvi 32Kb/h Intel DVI ADPCM 

3. gsm 16Kb/s GSM 

4. Ipcl 18Kb/s Linear Predictive Coder 

5. Ipc4 8Kb/s Linear Predictive Codex 

• Wliiteboard Wb is a Xll-based tool for shared drawing surface using 
an X-window among a group of users in the conference mode. Wb can 
also be used to export, view and annotate arbitrary PostScript files. 
To include PostScript images in the wb conference, the X-server has to 
either support Display PostScript or wb has to be able to exec the 
public domain postscript renderer GhostScript 

These programs were developed by Van Jacobson and his group at the 
Lawrence Berkeley Laboratory in the University of California, Berkeley 

The development of wb, vat, and sd were supported by the Director, Office" 
of Energy Research, Scientific Computing Staff, of the U S. Department of 
Energy under Contract No. DE-AC03-76SF00098. 

For the demonstration, gyan^ transport and csJOv/ere configured to par- 
ticipate in multicast session^ for audio and whiteboard conference 

The present implementation for IP multicast does not a.ssiue eirot free 
transmission of multicast datagrams and it is the responsibilty of the upper 
layers to recover the lost packets In the concluding part of this the.sis rcllabilty 
issues in IP nuiltica,st have been discussed. 



Chapter 5 


Conclusion 


In this project, low level group communication features such as multicasting, 
multicast routing and group management have been implemented on the IITK 
Campus netwoik A Multicast Backbone has been sot-up, to allow hosts on 
different subnets within the IITK LAN, to participate in applications such as 
conferencing This implementation is based on the public domain software 
available freely over the Internet, and has been modified to the extent needed 
for configutmg hosts, as multicast routers and for subnet routing. This setup 
was successfully demonstrated for audio and whiteboard applications. 

In the next section, the scope for furthur work is discussed 


5.1 Scope for Further Work 

As an immediate extension of tliis project, the development work on the en- 
hancement of the IITK-IP routers for multicast packet forwarding has already 
begun. 

One of the major drawbacks of this IP multicast implementation is that 
it provides only an unreliable datagram deliveiy mechanism due to the use of 
the RAW or UDP socket interfaces To enhance this implementation for use 
in applications having error-free datagram deliveiy rec[Liiremcnts, a reliable 
group communication interface will have to be built on top of the existing 
implementation of IP multicast The reliability aspects in IP multicast have 
been investigated by Armstrong et al [21], This RFC also details the IP 
multicast transport layer 

In the following section, a brief description of the various reliability char- 
acteristics in group communications are included 

Since this 2 :)iojcct has been initiated with the intention of pioviding con- 
ferencing on the Campus LAN at a future date, the concluding section of this 
thesis biielly outlines some of tlie issue.s involved in de.sigijiiig gioiiji ccmitiiu- 
nicdtion featuics for ical-time conferencing applications. 
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5.1.1 Reliable group communication 

The designeis of the IP multicast enhancements as standardised in [19] have 
chosen to use the unreliable datagram delivery mechanism, since the applica- 
tion for wluch this implementation was targeted was Audio and Video Con- 
fer enemy, wliK h does not have a strict error tocovery tefiniieiiienls nnil packet 
losses can be tolerated to some extent Applications such as iniilti-inedia 
iiiulti-souiK' mfoi Illation sci vices ie(]uiie the gioup coiiumiiiK atioii seivite to 
be loliabte Tlni-s, a combination of loliability mccliaiusms siuli as secfueiice 
numbers, timeouts and retransmission schemes have to be provided by the 
applications As the next level of enhancement, some reliability mechanism 
could be implemented in the upper layer to provide the use of IP multicast to 
applications requiring reliable group communications 

H.Garcia and A Spauster (12j have discussed reliable group communica- 
tions in detail and designed a protocol whose reliability can be evaluated based 
on a reliability criteria developed by them A gist of the reliability charac- 
teristics as outlined by them are reproduced here to highlight the reliabilty 
aspects in group communications. 

The various reliability characteristics are as follows 

• guarantee delivery of multicast datagram to group members based on 
the initiation time from the source 

• Guarantee relative delivery delay of a message to gioup members This 
means that, once a member receives a message, the othei members are 
guaranteed to leceive the message within some maximum delay, 

• Guarantee ordered delivery of multicast packets. 

• Force sites to roll back and deliver messages that have been lost or 
inconsistently delivered to some or all members 

5.1.2 Group communications for real-time conferencing 

When designing the IP multicast, the IETF aimed at providing loosely con- 
trolled teleconferences where the attendees simply tune in to an agreed-upon 
multicast address and begin transmitting and/or receiving data. There is no 
co-ordination between end-systems and the conference state is constructed 
asynchronously through passive receipt of control messages from other group 
members. In conferencing applications, group co-ordination is an important 
part of the confeience setup and control. The group-cordiiiation protocol 
would essentially 

• negotiate a common set of capabilities between tlie [laiticipaiit.s 
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• requrst paiticiparioti 

• initiate media connections 

• piopogatc infoimation among peers, and 

• provide state synchronization 

Inordor to provide such a session layer protocol for group co-ordination, 
at the transport layer, a group messaging serutce which provides efficient 
transactions is a must 

The Multimedia Conferencing project (H] has focused on the networking 
requiicmcnts and towaids tlxis end, have designed and impleiueiited a suite 
of expoiiinental jiarkot protocols that operate at a ninnbei of levels in the 
protocol stack As a next step in the direction of the development of multi- 
media conference control protocol, the development of a transport level [21] 
group messaging seivice for group communications could be taken up. 



Appendix A 


A.l The IGMP overview : 

Conceptually the IGMP is divided into two phases. 

• I’ll. I'll' I Will'll (I liii'il ii>iii!( II iii'w iiiull 11 inl I* 'ii'iiihi nil KiMI’ 

message to the predefined "all hosts gioup addiess" dcdanug its mem- 
bership The local multicast gateway receives the message and estab- 
lishes the necessary routing information 

• Phase 2 Because the membership may be dynamic, local multicast gate- 
ways periodically poll the hosts on the local netwrok to determine which 
hosts remain members. If no hosts report membership after the poll, the 
gateway stops advertising the group to other multicast routers, assum- 
ing that no hosts on the network are members of'that group IGMP is 
an asymmetric protocol. 


A.1.1 The IGMP implementation 

All IGMP coininuiiication between hosts and multicast gateways use IP mul- 
ticast. That is^ when IGMP messages are encapsulated in an IP datagram 
for transmission, the IP destination address is the all.hostii,multicast_address 
This has been done to avoid congesting a local network Thus, datagrams car- 
rying IGMP messgaes are hardware multicast if available. Also, a multicast 
gateway will not send individual request messages for each multicast groups. 
Instead, it sends a single poll message to request membership in all groups, 
The polling rate is restricted to atmost one request per minute. Hosts that 
are members of multiple groups do not send multiple i espouses at the same 
time but wait for a random time between 0 to 10 sees , During this time the 
hosts listen to responses from other hosts and supress any responses that are 
unnecessary Gateways do not keep an exact record of the group momborship 
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and need to know only whether atleast one host on the local notwoik icmains 
a membei of the gioiip Dy spacing the losponscs an<l iisteimig to othei hosts 
responses , effectively only one host each group responds to a request message 
from a multicast gateway. This method has been used to reduce all unneces- 
sary transmissions on the netwoik. 


A. 1.2 The IGMP State Transition Diagram : 

The IGMP must remember the status of each multicast group to which the 
host belongs. The host keeps a table m which the group niembeiship infor- 
mation IS recorded Initially, all entries are unused Whenever, an application 
program on the' host joins a new gioiip, IGMP softwaie allm ates an entry and 
fills m the infoimation of the gioup Among the information, IGMP keeps 
a group refeience counter which it initializes to 1 If any other application 
program also joins that group the counter is incremented As the application 
program drops out from the group, thr group lefernce countci deciements 
The host leaves the group when the counter reaches zeio 



Figure A T IGMP State Transition Diagram 

The action IGMP takes in response to IGMP messages can be bc.st under- 
stood by the state transition diagram in Figure A 1, As the figure shows, a 
single timer mechanism can be used to generate both the initial re, spon.se mo.s- 
sage as well as re.sponses to request from multicast gateways. A rG(iue.st to join 
the group places the entry in the TIMER ACTIVE state and sets the timer to 
a small value. When the timer expires, IGMP generates and sends a re.sponsc 
rne.ssage and moves the entry to the MEMBER state. In the MEMBER state. 
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reception of an IGMP query causes the software to choose a tiincout value, 
stait a tuner ontiy, and move the entry to the TIMER ACTIVE state If an- 
other host sends a lesponsc foi the multicast gtouij hefoK' the tiiiiei ex[)iies, 
IGMP camels the tiiiiei and moves the entiy h.uk to the MEMI3ER state 


A. 2 The IGMP message format : 

The IGMP message format is as shown m the Figure A 2 


VMt'< ni'i. 


IINI IS|i|> 


( I [l'< KMIM 



GROUP ADDRESS ( 0 IN QUERY ) 


Figure A. 2 IGMP Message Format 

1. VERS = the protocol version (currently 1) 

2. TYPE = 1 query sent by the multicast gateway; 

TYPE = 2 : response 

The Distance Vector Multicast Routing Piotocol which is an experimen- 
tal protocol for routing multicast packets, defines additional TYPE (3) 
for use in DVMRP messages. 

3. UNUSED = zero 

4 CHECKSUM field contains a checksum for the 8-octet IGMP message 

5. GROUP ADDRESS = address of the group being rcpoitcd in response 
message. 

The IGMP is used to carry routing messages between roiiteis 
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Appendix B 


B.l The DVMRP Commands 

A DVMRP command consists ofaa8-bit command numciic code, with atleast 
8-bit data poi tion The conunands as specified in RFC1075 [18] arc icproduccd 
below : 

• NULL Command • 0 
Data Unused 

Description: The NULL command can be used to piovide additional 
alignment or padding to 32 bits. 

• Address Family Indicator (AFI) Command AFI Command 02 
Data’ Family 

Values for family 

2 = IP address family, in which addresses are 32 bits long 
Default Family = 2 

Description: The AFI command provides the address family for subse- 
quent midie.ss’os in the sticam (until a diflciont AFI command is given). 
It IS an error if the receiver does not support the address family. 

• Subnetmask Command 03 
Data 

1 count ■ 0 or 1 

2. Additional argument, with AFI = IP: SubnGtma.sk 4 bytes 

Default’ Assume that following routes are to networks, and use a ma.sk 
of the netwoik mask of each route's destination. 



Description* Tlie Subnetm<isk command provides tiio subnet mask to 
use foi sub'iociuont routes There aie some icquiiomoiits on the bits in 
the subiK'tmask bits 0 thiough 7 must be 1, and all of the bits must 
not be 1 

If the count is 0, then no subnet mask applies, assume that the following 
routes are to networks, and use a mask of the notwoik mask of each 
route’s destination If count is 1, then a subnet mask should be in the 
data stream, of an appropriate size given the addiess family 

It is an error for count not to equal 0 or 1. 

Subnet masks should not be sent outside of the appropriate network 

Metin. Cumin. iiul 04 
Data Val ue 

Value IS the rnetiic, as an unsigned value ranging from 1 to 255. 
Default. None. 

Description: The metric command provides the metric to subsequent 
destinations The mcLnc is relative to the router that sent this DVMRP 
routing update 

It is an error for metric to equal 0 

FlagsO Command • 05 

Data Value Meamng of bits in the value 

Bit 7 Destination is unreachable Bit 6 Split Horizon concealed route. 
Default All bits zero. 

Description: The flagsO command provides a way to set a number 
of flags The only defined flags, bits 6 and 7, can be used to provide 
more information about a route with a metric of infinity A router that 
receives a flag that it does not support should ignore the flag 

The command is called flagsO to peimit the definition of additional flag 
commands in the future (flagsl, etc.). This is an experimental command, 
and may be changed m the future. 

Infinity Command . OC 
Data : Value 

Value IS the infinity, as an unsigned value ranging fiom 1 to 255 
Default: Value = 16. 

Description: The infinity command defines the infinity for subsequent 
metrics in the stream 



It IS ati error for iiitiiiity to be zeio, or less than the cm rent metric 

Destination Address (DA) Command . 07 
Data Count 

Array of ‘count’ additional argiimonts, with AFI = IP Destination 
Adresses 

Count IS tlu’ miinboi of aiMiesiies supplied, fiotn 1 to 255. The length 
of the adili Cisiv-i depends upon (he iiuieiil addi'ess fitjoily ’Dii* niinibei 
of addiesses supplied is subject to the message length limitation of 512 
bytes. 

Default None. 

Description: The DA command provides a list of destinations Wlule 
this format can express routes to hosts, the routing algorithm only sup- 
ports network and subnetwork routing The curient metric, infiruty, 
fldgsO and subnetmask, when combined with a single destination ad- 
dress, define a route The current metric must be less than or equal to 
the current infinity 

It IS an error for count to equal 0. 

Requested Destination Address (RDA) Command 08 
Data Count 

Array of ‘count’ additional arguments, with AFI — IP. Destination Ad- 
dresses, 

Count IS the number of addresses supplied, fiom 0 to 255 The length 
of the addresses depends upon the current address family The number 
of addresses supplied is subject to the message length limitation of 512 
bytes 

Default: None. 

Description: The RDA command provides a list of destinations for 
whom routes are requested. A routing request for all routes is encoded 
by using a count = 0 

Non Membership Repoit (NMR) Command 09 
Data ' Count 

Array of ‘count’ additional arguments, with AFI = IP. Multicast ad- 
dresses, followed by the hold-down timer value (4 bytes eacli). 

Count is the number of Multicast Address and Hold Down Time paiis 
supplied, from 1 to 255, The length of the addie,sso.s depends upon the 



current address family. The number of pairs supplied is subject to the 
message length limitation of 512 bytes. 

Default None 

Description: The NMR command is experimental, and has not been 
tested in an implementation. Each multicast address and hold down 
time pair is called a non-membership report. The non-membeislup re- 
port tells the receiving router that the sending router has no dcscendcnt 
group members in the given group. Based on this information the receiv- 
ing router can stop forwarding datagrams to the sending router for the 
particular multicast address(es) Usted The hold down time indicates, 
in seconds, how long the NMR is valid. 

It is an error for count to equal 0 The only other commands in a message 
that has NMR commands can be the API, flagsO, and NULL commands. '■ 
No relevant flags for the flagsO command are currently defined, but that 
may change in the future. 

• Non Membership Report Cancel (NMR Cancel) Command ■ 10 
Data • Count 

Array of ‘count’ additional arguments, with API = IP: Multicast ad- 
dresses 

Count IS the number of Multicast Addresses supplied, from 1 to 255 The 
length of the addresses depends upon the current address family. The 
number of addresses supplied is subject to the message length limitation 
of 512 bytes 

Default: None. 

Description: The NMR Cancel command is experimental, and has not 
been tested in an implementation. For each multicast address listed, any 
previous corresponding non-membership reports are canceled. When 
there is no corresponding non-membersliip report for a given multicast 
address, the Cancel command should be ignored for that multicast ad- 
dress 

It is an error for count to equal 0. The only other commands in a mes- 
sage that has NMR Cancel commands can be the API, flagsO, and NULL 
commands. No relevant flags for the flagsO command are currently de- 
fined, but that may change In the future. 

An example : 

Supplying a route to the IP addresses 128 2 251.231 and 128.2 236.2 with 
a metric of 2, an infinity of 16, a subnctma.sk of 255 255.255.0' 

Subtype 1, 
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AFI 2, Metric 2, Infinity 16, Subnet Mask 255.255 255.0 
[2] [2] [4] [2] [6] (16] (3) (1) (255) (255) (255) [0] 

DA Count=2 (128.2.251.231) [128.2.236.2] 

(7) [Ij (128) (2) [251] [231] [128] (2) [236] [2] 


B.2 Route Report Processing 

For each route expressed in a routing message, the following must occur’ 


IF a metric was given for the route: 

THEN add in the metric of the virtual interface 
that the message arrived on. 

Lookup the route's destination address in the 
routing tables. 

IF the route doesn't exist in the tables: 

THEN try to find a route to the same 
network in the routing tables. 

IF that route exists in the tables: 

THEN IF this route came from the 
same router as the router 
that the found route came from: 

THEN CONTINUE with next route. 

IF route doesn't have a metric of infinity: 
THEN add the route to the routing tables. 

CONTINUE with next route. 

IF this route came from the same router as 
the router that the found route came from: 
THEN clear the route timer. 

IF a metric was received, and it is 

different than the found route's metric: 
THEN change the found route to use the new 
metric and infinity. 

IF the metric is equal to the infinity: 
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THEN set the route timer to the 
EXPIRATION.TIMEOUT. 

CONTINUE with next route. 

IF the received infinity does not equal the 
found route’s infinity: 

THEN change the found route’s infinity to he 
the received infinity, 
change the f^'und route’s metric to be 
the minimum of the rece,ived infinity and 
the found route’s metric. 

ELSE IF a metric was received, and (it is less than the 
found route’s metric or (the route timer is 
atleast halfway to the EXPIRATION_TIMEOUT and 
the found route’s metric equals the received 
metric, and the metric is less than the received 
infinity) ) : 

THEM change the routing tables to use the received 
route, clear the route timer, 

CONTINUE with the next route, 


B.3 Algorithm For Manipulating Leaf and ~ 
Child Interfaces 

The algorithm for manipulating the children and leaf lists in route entries is: 
Upon router startup. 

Create a route entry for each virtual interface, with' 

• all other virtual interfaces in its child list, 

• an empty leaf list, 

• no dominant router addresses, and 

• no subordinate router addresses. 

Start a hold down timer for each v-irtual inter face, with a value of LEAF„- 
TIMEOUT 
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Upon receiving a new route 

Create the route entry, with’ 

• all virtual interfaces, other than the one on which the new route was 
received, in its child list, 

• empty leaf list, 

• no dominant router addresses, and 

• no subordinate router addresses 

Start the hold down timer for all virtual interfaces, other than the one on 
which the new route was received, with a value of LEAF .TIMEOUT, 

Upon receiving a route on virtual interface V from neighbor N with a lower 
metric than the one in the routing table (or the same metric as the one in the 
routing table, if N’s address is less than my address for V), for that route- 

IF V is in the child list, 

delete V from the child list. 

IF there is no dominant router for V and 
IF V is not (now) the next-hop virtual 
interface, record N as the dominant router. 

Upon receiving a route on virtual interface V from neighbor N with a larger 
metric than the one in the routing table (or the same metric as tlie one in the 
routing table, if N’s address is greater than my address for V), for that route: 


IF N IS the dominant router for V, 
delete N as the dominant router 
cmd add V to the child list. 


Upon receiving a route from neighbor N on virtual interface V with a 
metric equal to infinity (the split horizon flag should also be set), for that 
route 


IF V is in the leaf list, 

delete V from the leaf list. 

IF there is no subordinate router for V, 
record N as the subordinate router. 


73 



upon receiving a route from neighbor N on virtual interface V with a 
metric other than infinity (and no split horizon flag), for that route: 


IF M IS the subordinate router for V, 

ilololo N nn llin niihoi d 1 u r\ In toiil.n] niid 
Start the hold dovm timer for V. 


Upon timer expiration for a virtual interface (V), for each route. 


If there is no subordinate router for V, 
add V to the leaf list. 

Upon failure of neighbor M on virtual interface V, 
for each route . 

If N IS the dominant router for V, delete N as the 
dominant route and add V to the child list. 

If N is the subordinate router for V, delete N as 
the subordinate router and start the hold down 
timer for V. 


B.4 Timer Values 

This section contains a list of the various rates and timeouts, their meanings, 
and their values. All values are in seconds. 

How dynamic the routing environment is effects the following rates. A 
lower rate will allow quicker adaptation to a change in the environment, at 
the cost of wasting network bandwidth 

FULL.UPDATE.RATE = 60 

- How often routing messages containing complete routing tables are sent. 

TRIGGERED .UP DATE-RATE = 5 

- How often triggered routing messages may be .sent out. 

Raising the following rates and timeouts may increase the time tliat packets 
may be forwarded to a virtual interface unnecessarily 

QUERY.RATE - 120 
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- How often local group membership is queried. 


MEMBERSHIP.TIMEOUT = 2 * QUERY.RATE + 20 

- Haw long a local group membership is valid without confirmation. 

LEAF.TIMEOUT = 2 * FULL_UPDATE-RATE -H 5 

- How long the hold down timer is for a virtual interface. 

Increasing the following timeouts will increase the stability of the routing 
algorithm, at the cost of slower reactions to changes in the routing environ- 
ment. 

NEIGHBOR-TIMEOUT = 4 * FULL-UPDATE.RATE 

- How long a neighbor is considered up without confirmation. This is 
important for timing out routes, and for setting the children and leaf flags. 

EXPIRATION.TIMEOUT = 2 * FULL-UPDATE_RATE 

- How long a route is considered valid without confirmation. When this 
timeout expires, packets will no longer be forwarded on the route, and routing 
updates will consider this route to have a metric of infinity 

GARBAGE.TIMEOUT = 4 * FULL-UPDATE.RATE 

- How long a route exists without confirmation When this timeout expires, 
routing updates will no longer contain any information on this route, and the 
route will be deleted 
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Appendix C 


C.l Network Subsystem 

In the UNIX operating system, network facilities are accessed through the 
"socket" abstraction for data transfer. A network subsystem provided by the 
UNIX network environment provides facilities such as : 

• A structured inteiface to the socket level, that allows the development 
of network-independent application software. 

• A consistent interface to the hardware devices used to transmit and 
receive data 

• Network independent support for message routing 

• Memory management. 

The detailed description of the above is given in the 4 3BSD Unix Oper- 
ating system manual [13). 

C.1.1 Internal structure 

Internally, the network subsystem is logically divided into three layers to man- 
age the following tasks : 

Interprocess data transport 

Internetwoik addressing and message routing 

Transmission media support. 

The first two layers are made up of modules that implement cornmunlca- 
tion protocol; the software in the third layer is structurally much like a device 
driver. In the DARPA TCP/IP networking architecture those functions arc 
handled by the three layers as described in (7). The Figiue C.l illustrates 
the data flow across the layers in a network subsystem. The data, flows 
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Figure C 1. Data Flow acioss the layers in a Netwoik Subsystem 

down to the network subsystem from the socket layer, tliiough system calls to 
the transport layer modules that support the socket abstraction. The upward 
flow of data Is asynchronously received, and passed fiom the netwoik interface 
layer, to the appropriate communication protocol through per-protocol input 
message queues, "Software Interrupts" are used to schedule asynchronous 
network activity, The system schedules network protocol processing from the 
network-interface layer by marking a bit assigned to the protocol in the sys- 
tems’ network intcnupt status word and posts a "software inteirupt" reserved 
for triggering network activity The received data passes upwards through the 
communication protocols until it is placed in the receive queue of the de.sti- 
nation socket. Each communication piotocol modulo, for e g the DARPA 
TCP/IP, is made up of a collection of procedure.? and private data structure.? 

Protocols are described by a protocol switch structure C.2 that contains 
the set of cxteinaliy visible entry points and attiibiitos. The socket layer 


77 



protocol identifiers 


socket-protocol 

interface 

protocol-protocol 

interface 


utility routines 



Figiiie C 2 Protocol Switch Arclutectuie 

interacts with a communication protocol only through the later’s protocol 
switch stiiictuie, recording the structiu'e’s addiess in the socket’s .so.pioLo 
field. For more details refer Stevoas : Unix Network Programming [24] 

A network interface configured in a system, manipulates the hardware 
device and is responsible for encapsulation and decapsulation of any link-layer 
protocol header required to deliver a message to its destination, The selection 
of the network interface to use in delivering a packet, is a routing decision 
taken at tlie network layer of the particular protocol (e g IP layer in the 
TCP/IP piotocol suite. A particular intciface may have ad(]j('s.s(;.s in one or 
more address families. The interface addresses are setup at boot time u.sing 
"ioctl" system call on a socket, in the appropriate domain Tlie uiteiface and 
Its addi esses are stored m a stiuctuie. 
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